Prefer &str to &String because it is more versatile.

Anyway, I would consider keeping both arguments together as part of the same thing:

struct Certificate { // well, I suck at naming...
  content: String,
  key: String
}

impl Certificate {
  pub read(cert: &str, key: &str) -> Result<Self>;
  pub new() -> Self; // generates the content
}

Then you can use the same code:

tls_builder.set_certificate(crt.content.as_ref());
tls_builder.set_private_key(crt.key.as_ref());

And as a bonus, you could test the certificate creation in isolation (without having anything to do with the acceptor).

This code could be part of the Certificate struct I mentioned before.

so basically we create certificate that is valid from today for a next year. Question is are we sure we have correct date in agama? if not, then it can be issue with remote browser, that will have different date.

Ah, good point. On the other hand the certificate is self-signed so the browser will complain anyway. Wrong date will make the problem just a little bit more serious. 😄

We could use something like

// Jan 1 1970 00:00 UTC
let not_before = Asn1Time::from_unix(0)?;
// Jan 1 2040 00:00 UTC 
let not_after = Asn1Time::from_str_x509("20400101000000Z")?;

This would cover bigger range.

Anyway, I guess this will be reviewed by the security team later so this might change...

Uh, wrong date would even make troubles connecting to other remote https resources like SCC. As a solution we should probably run NTP synchronization on the Live ISO...

There is no need to change it now (time pressure), but it is weird that ServeArgs is responsible for creating the SSL acceptor.

If the server listens on two ports then it would be a good idea to use the same generated self-signed certificate on both ports. So the SSL acceptor needs to be created early. I added a TODO mark.